System and method for inserting data into an internet browser form

ABSTRACT

Systems, methods, and computer-readable storage media for inserting payment information into payment forms without user interaction. A system can identify that a user has navigated to a web page operated by a merchant computer system for a merchant and identify a payment form within the web page. The system can then execute a payment request API which generates a query for saved payment credentials for the user from the merchant computer system. When the merchant computer system indicates it does not have the saved payment credentials for the user, the system can identify browser-saved payment credentials stored in the Internet browser, then generate a virtual payment information associated with the browser-saved payment credentials. The virtual payment information can then be inserted into corresponding fields of the payment form without the user entering any additional information.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/790,871, filed on Feb. 14, 2020, the content of which is herebyincorporated by reference in its entirety.

BACKGROUND 1. Technical Field

The present disclosure relates to insertion of information into a formwithin a web browser, and more specifically to automatically obtainingand providing private data upon an API determining that a merchantwebsite does not have the private data saved.

2. Introduction

Technology which assists a user in typing or entering information isgenerally based on a computer's ability to predict what a user is typingor otherwise entering into a computer. For example, users of a searchengine may be presented with suggested queries based on their previoussearches and/or based on similar searches conducted by other users. Asanother example, a user typing a text message (e.g., a SMS message,“Short Message Service) may have words suggested based on the context ofthe message, the intended recipient, previous text messages received,previous text messages sent, etc.

With respect to private data, such as a user's credit card information,some Internet browsers can save a user's data, then enter the data uponreceiving authorization from a user. For example, such browsers cansuggest autocompletion of the respective fields with private data as theuser begins entering data into the fields, with the user hitting “enter”to provide authorization for the autocompleted forms. In otherinstances, merchants can save a user's checkout information, such asaddress, credit card information, etc., and, upon receivingauthorization from the user, fill in the respective fields based on thesaved data. However, in both instances, the checkout process is slowedby the need to receive explicit permission from the user before enteringthe private data into the fields.

SUMMARY

Additional features and advantages of the disclosure will be set forthin the description which follows, and in part will be obvious from thedescription, or can be learned by practice of the herein disclosedprinciples. The features and advantages of the disclosure can berealized and obtained by means of the instruments and combinationsparticularly pointed out in the appended claims. These and otherfeatures of the disclosure will become more fully apparent from thefollowing description and appended claims, or can be learned by thepractice of the principles set forth herein.

Disclosed are systems, methods, and non-transitory computer-readablestorage media a technical solution to the technical problem described. Amethod for performing the concepts disclosed herein can include:identifying, via a processor operating an Internet browser, that a userhas navigated to a web page operated by a merchant computer system for amerchant; identifying, via the processor, a payment form within the webpage; executing, via the processor, a payment request applicationprogramming interface (API), the payment request API having executablecode distinct from the Internet browser, the payment request APIgenerating a query for saved payment credentials for the user from themerchant computer system; receiving, from the merchant computer systemin response to the query, an indication that the merchant computersystem does not have the saved payment credentials for the user; uponreceiving the indication, identifying, via the processor, browser-savedpayment credentials stored in the Internet browser; generating, via theprocessor, a virtual payment information associated with thebrowser-saved payment credentials; and inserting, via the processor, thevirtual payment information into corresponding fields of the paymentform without the user entering any information into any of thecorresponding fields.

A system configured to perform the concepts disclosed herein caninclude: a processor; and a non-transitory computer-readable storagemedium having instructions stored which, when executable by theprocessor, cause the processor to perform operations comprising:identifying that a web browser operated by a user has downloaded amerchant web page operated by a merchant; identifying, by matching fieldnames within the merchant web page, a payment form within the merchantweb page; initiating a payment application programming interface (API),the payment API having executable code distinct from the web browser,the payment API querying the merchant for saved credit card informationassociated with the user; receiving, from the merchant, a notificationthat the merchant does not have the saved credit card information forthe user; upon receiving the notification, retrieving stored credit cardinformation saved in the web browser; inserting stored credit cardinformation into fields of the payment form prior to the user enteringany information into any respective field of the payment form.

A non-transitory computer-readable storage medium configured asdisclosed herein can have instructions stored which, when executed by acomputing device, cause the computing device to perform operations whichinclude: identifying a payment form within a webpage being viewed,through a browser, by a user; and upon identifying the payment form,executing a payment application programming interface (API), the paymentAPI having executable code distinct than that of the browser, thepayment API performing operations comprising: transmitting a query to anoperator of the webpage, the query requesting payment informationassociated with the user; receiving, from the operator in response tothe query, a notification that the operator does not have the paymentinformation associated with the user; retrieving stored paymentinformation within the browser; transmitting, to a third party, thestored payment information; receiving, from the third party, a virtualcredit card information associated with the stored payment information;and inserting the virtual credit card information into the payment formbefore the user manually enters any payment information into the paymentform.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example system embodiment;

FIG. 2 illustrates a prior art example of communications between a user,a merchant site, a browser, and a browser extension;

FIG. 3 illustrates example communications between a browser extension, amerchant site, and a payment handler backend as disclosed herein;

FIG. 4 illustrates an example method embodiment; and

FIG. 5 illustrates an example computer system.

DETAILED DESCRIPTION

Various embodiments of the disclosure are described in detail below.While specific implementations are described, it should be understoodthat this is done for illustration purposes only. Other components andconfigurations may be used without parting from the spirit and scope ofthe disclosure.

The present disclosure addresses obtaining and entering of private datainto fields within an Internet browser. In one example, the methods andsystems allow a program or application (“app”) to insert privateinformation not stored within that program or app, and to then use thatinformation. Account controls may be provided which allow for control ofwhich information may be accessed. Whereas previous systems requiredexplicit permission from the user to enter stored private data, themethods, systems, and computer-readable media disclosed herein can, uponfollowing specific rules and requirements, directly enter the privateinformation into the corresponding fields of the Internet browserwithout the need for explicit permission from the user. By automaticallyentering private information of a user automatically obtained into thecorresponding fields, the process of completing the form is increased.

As described herein, private data can be any form of controlled userdata. Examples of private data can include identification information,such as social security numbers, addresses, date of birth, phonenumbers, email addresses, social media handles, names of family members(and associated identification information), credit card information,bank account information, login/password information, etc. In someinstances, private data may be publicly available (such as an emailaddress), however it may not be desirable to share that information atall times, in which case it would default to private data.

Consider the following example. A user is browsing the Internet using anInternet browser, such as CHROME, FIREFOX, INTERNET EXPLORER, etc. Asthe user browses a merchant's website, the user decides to make apurchase. The merchant's website, upon receiving from the user anindication to make the purchase, illustrates a payment form with variousfields for the user's credit card number, name, address, etc. A browserextension, executes an API (Application Programming Interface), whichsends a query to the merchant's website. The query includes a requestfor payment information. The payment information may be, for example,information which the user had previously used and which was previouslysaved by the merchant. In this example, the merchant's website respondsby indicating that it does not have the user's payment informationstored. In response to this, the browser extension (or the browser)identifies payment information stored within the browser, retrieves thatinformation, and fills the payment form fields with the correspondingpayment information. The filling of the payment form fields with thestored payment information occurs without the user entering anyinformation into the corresponding fields, and without the userotherwise giving permission to the browser extension to do so.

The code executing the browser extension can be separate, distinct codethan the browser code, but configured to operate with the browser code.In other configurations, the browser extension code can be a specificportion or part of the browser code which can be enabled, or disabled,by the user.

In some configurations, rather than the filling of the fields withoutthe user entering any information, the system can be configured toautomatically enter the private data only once the user enters apredetermined amount of data perfectly corresponding to the savedprivate data. For example, stored credit card information can be enteredautomatically (without user confirmation) once the user enters the firstfour digits of the credit card information.

In some configurations, rather than inserting saved private data, suchas payment information saved within the browser, the system can insteadgenerate virtual payment information associated with saved paymentcredentials. For example, upon receiving a notification that themerchant site does not have saved payment credentials from the user,and/or upon determining that the user has entered a minimum amount ofthe saved data, the system can generate a virtual credit card number (orother payment authorization code). The virtual credit card number is avalid credit card number which is not associated with any physical card.

This virtual credit card number can then be entered into the browserfields in place of the saved payment information. In someconfigurations, generation of the virtual credit card number can occurat a third party computing system/server. For example, thebrowser/browser extension (or the processor executing the browser code)can request that a third party server generate the virtual credit cardnumber, then forward the virtual credit card number to thebrowser/browser extension for entry. In certain configurations, thebrowser and/or the third party server can generate distinct virtualcredit card numbers for respective merchants. Having distinct virtualcredit card numbers for respective merchants can reduce fraud becausewhen a user's virtual credit card number associated with a firstmerchant is being used with a second merchant, the system canautomatically flag the account as compromised and cancel the number.Having virtual credit card numbers associated with a specific merchantalso reduces the amount of time needed to identify fraud andreduce/eliminate any potential ramifications of that fraud.

With that basis, the disclosure turns to the examples provided in theillustrations. FIG. 1 illustrates an example system embodiment 100. Asillustrated, a user 102 is interacting with a user device 104. The userdevice 104 can communicate over a network 106, such as the Internet,with a merchant website server 108, a service provider device 110, and adata storage device 112. As an example, the user 102, using the userdevice 104, can navigate a web browser to a webpage operate by themerchant web server 108. The user 102 can select an option to make apurchase from the merchant website, and the web browser on the userdevice 104 can request, from the merchant web server 108, if themerchant web server 108 has any stored payment credentials associatedwith the user 102 or the user device 104. If the merchant web server 108replies that it does not have any payment credentials stored, the userdevice 104 can determine if it has any payment credentials stored withinthe device 104. For example, the user device 104 may have the paymentcredentials stored within computer-readable memory. Alternatively, theuser device 104 may communicate with a data storage device 112 acrossthe network 106, querying the data storage device 112 for stored paymentcredentials.

When stored payment credentials are identified, the service providerdevice 110, which can, for example, be a server operated by a servicescompany, can generate a virtual credit card number (or othervirtual/non-physical payment account) associated with the stored paymentinformation. The service provider device 110 can then provide thatvirtual payment information to the user device 104, which canautomatically load the virtual payment information directly into paymentforms associated with the purchase process for the product.

FIG. 2 illustrates a prior art example of communications 200 between auser 202, a merchant site 204, a browser 208, and a browser extension206. While illustrated as distinct, in some configurations the browserextension 206 can be built into the browser 208 code as a unique portionof the browser code which can be enabled or disabled. In this example200, the user 202 seeks to checkout 210 within the merchant site 204.The processor, configured as disclosed herein, detects that the user 202is on the checkout form 212. This may be done automatically. Once thepayment form is detected, the browser extension invokes a paymentrequest API (Application Programming Interface) 214 to obtain previouslystored credit card data. In this example, the user interacts 216 withthe browser 208 to provide the payment information, which is thenreturned 218 from the browser 208 to the browser extension 206. At thatpoint, the system can automatically enter credit card data 220 into thecorresponding fields of the merchant site payment form.

By contrast, FIG. 3 illustrates example communications 300 between abrowser extension 306, a merchant site 302, and a payment handlerbackend 314 as disclosed herein. Rather than needing user interaction,the illustrated communications can fill a payment form 322 without anydirect user interaction once the user browses to a merchant site 302.Once a processor, configured as disclosed herein, detects that the useris on a checkout form 304, a browser extension 306, having code which isdistinct from a browser, sends a payment handler request 308 to apayment handler/payment request API 310. The payment hander 310, in thisexample, authenticates the user 312 by communicating with the paymenthandler backend 314. In some configurations, an authentication of anidentity of the user by the payment handler backend 314 may have alreadyoccurred, and this authentication 312 is exclusively associated withpreviously stored payment information of the user.

The payment handler backend 314 responds to the authentication request312 with the previously stored card information 316, which the paymenthander 310 returns 318 to the browser extension 306. The browserextension 306 then automatically enters 320 the payment form 322 on themerchant website 302, such that the user sees an already-filled paymentform. At that point, the user only needs to confirm the purchase byselecting the “Buy Now” button 324.

FIG. 4 illustrates an example method embodiment. In this example, themethod is performed by a system (such as a computing device with aprocessor) operating an Internet browser. The processor identifies thata user has navigated to a web page operated by a merchant computersystem for a merchant (402). This recognition can occur based on acomparison of known websites to the current website, based on adesignation of the website (e.g., “.com”), or in other known ways ofwebsite detection. The processor identifies a payment form within theweb page (404). This identification can occur, for example, by theprocessor performing a text comparison on text loaded into the webpage,searching for terms such as “credit card number” and “expiration date.”In applications associated with private, non-payment information, theform may be looking for “social security number” or “date of birth.”

The system executes, via the processor, a payment request applicationprogramming interface (API), the payment request API having executablecode distinct from the Internet browser, the payment request APIgenerating a query for saved payment credentials for the user from themerchant computer system (406). The system receives, from the merchantcomputer system in response to the query, an indication that themerchant computer system does not have the saved payment credentials forthe user (408) and, upon receiving the indication, identifies, via theprocessor, browser-saved payment credentials stored in the Internetbrowser (410). The system generates, via the processor, a virtualpayment information associated with the browser-saved paymentcredentials (412) and inserts, via the processor, the virtual paymentinformation into corresponding fields of the payment form without theuser entering any information into any of the corresponding fields(414).

In some configurations, the system can tokenize, via the processor, thevirtual payment information, resulting in tokenized card data, where thevirtual payment information inserted into the corresponding fields ofthe payment form is the tokenized card data.

In some configurations, the insertion of the virtual payment informationinto the corresponding fields of the payment form occurs prior to theuser scrolling, within the Internet browser, to the payment form of theweb page. That is, the processor detects that there is a portion of thewebpage which contains a payment form, that portion is not yet displayedon the screen, and the processor executes the steps of the illustratedmethod prior to the user scrolling to that portion of the webpage.

In some configurations, the browser-saved payment information caninclude credit card data stored by the browser, where the virtualpayment information is generated specifically for the merchant.

In some configurations, the insertion of the virtual payment informationdoes not occur until the user enters a minimum amount of identifyinginformation. For example, the user may need to enter the first threedigits of their credit card information before any portion of the storedcredit card information appears. Likewise, the user may need to providea minimum amount of confirmation information prior to virtual creditcard information being inserted. Non-limiting examples of the minimumamount of identifying information can include a predetermined number ofdigits from the browser-saved payment credentials, an identification anda password, and/or a biometric identification.

In some configurations, the executing of the payment request API by theprocessor is initiated by the user interacting with a portion of agraphical user interface (GUI) of the Internet browser.

In some configurations, the illustrated method can further include:transmitting, through the Internet browser, the payment form with thecorresponding fields filled with the virtual payment information. Thatis, the method can include transmitting the completed form to themerchant.

In some configurations, the illustrated method can be augmented toinclude: receiving, prior to the generation of the virtual paymentinformation, a remaining portion of the payment information from theuser, where the virtual payment information is further associated withthe remaining portion.

In some configurations the virtual payment information comprises avirtual credit card number. In such configurations, the payment requestAPI can further request the saved payment credentials from a third partydatabase, where, upon inserting the virtual payment information into thecorresponding fields, the payment request API stores the virtual paymentinformation in the third party database.

With reference to FIG. 5 , an exemplary system includes ageneral-purpose computing device 500, including a processing unit (CPUor processor) 520 and a system bus 510 that couples various systemcomponents including the system memory 530 such as read-only memory(ROM) 540 and random access memory (RAM) 550 to the processor 520. Thesystem 500 can include a cache of high-speed memory connected directlywith, in close proximity to, or integrated as part of the processor 520.The system 500 copies data from the memory 530 and/or the storage device560 to the cache for quick access by the processor 520. In this way, thecache provides a performance boost that avoids processor 520 delayswhile waiting for data. These and other modules can control or beconfigured to control the processor 520 to perform various actions.Other system memory 530 may be available for use as well. The memory 530can include multiple different types of memory with differentperformance characteristics. It can be appreciated that the disclosuremay operate on a computing device 500 with more than one processor 520or on a group or cluster of computing devices networked together toprovide greater processing capability. The processor 520 can include anygeneral purpose processor and a hardware module or software module, suchas module 1 562, module 2 564, and module 3 566 stored in storage device560, configured to control the processor 520 as well as aspecial-purpose processor where software instructions are incorporatedinto the actual processor design. The processor 520 may essentially be acompletely self-contained computing system, containing multiple cores orprocessors, a bus, memory controller, cache, etc. A multi-core processormay be symmetric or asymmetric.

The system bus 510 may be any of several types of bus structuresincluding a memory bus or memory controller, a peripheral bus, and alocal bus using any of a variety of bus architectures. A basicinput/output (BIOS) stored in ROM 540 or the like, may provide the basicroutine that helps to transfer information between elements within thecomputing device 500, such as during start-up. The computing device 500further includes storage devices 560 such as a hard disk drive, amagnetic disk drive, an optical disk drive, tape drive or the like. Thestorage device 560 can include software modules 562, 564, 566 forcontrolling the processor 520. Other hardware or software modules arecontemplated. The storage device 560 is connected to the system bus 510by a drive interface. The drives and the associated computer-readablestorage media provide nonvolatile storage of computer-readableinstructions, data structures, program modules and other data for thecomputing device 500. In one aspect, a hardware module that performs aparticular function includes the software component stored in a tangiblecomputer-readable storage medium in connection with the necessaryhardware components, such as the processor 520, bus 510, display 570,and so forth, to carry out the function. In another aspect, the systemcan use a processor and computer-readable storage medium to storeinstructions which, when executed by the processor, cause the processorto perform a method or other specific actions. The basic components andappropriate variations are contemplated depending on the type of device,such as whether the device 500 is a small, handheld computing device, adesktop computer, or a computer server.

Although the exemplary embodiment described herein employs the hard disk560, other types of computer-readable media which can store data thatare accessible by a computer, such as magnetic cassettes, flash memorycards, digital versatile disks, cartridges, random access memories(RAMs) 550, and read-only memory (ROM) 540, may also be used in theexemplary operating environment. Tangible computer-readable storagemedia, computer-readable storage devices, or computer-readable memorydevices, expressly exclude media such as transitory waves, energy,carrier signals, electromagnetic waves, and signals per se.

To enable user interaction with the computing device 500, an inputdevice 590 represents any number of input mechanisms, such as amicrophone for speech, a touch-sensitive screen for gesture or graphicalinput, keyboard, mouse, motion input, speech and so forth. An outputdevice 570 can also be one or more of a number of output mechanismsknown to those of skill in the art. In some instances, multimodalsystems enable a user to provide multiple types of input to communicatewith the computing device 500. The communications interface 580generally governs and manages the user input and system output. There isno restriction on operating on any particular hardware arrangement andtherefore the basic features here may easily be substituted for improvedhardware or firmware arrangements as they are developed.

Use of language such as “at least one of X, Y, and Z,” “at least one ofX, Y, or Z,” “at least one or more of X, Y, and Z,” “at least one ormore of X, Y, or Z,” “at least one or more of X, Y, and/or Z,” or “atleast one of X, Y, and/or Z,” are intended to be inclusive of both asingle item (e.g., just X, or just Y, or just Z) and multiple items(e.g., {X and Y}, {X and Z}, {Y and Z}, or {X, Y, and Z}). The phrase“at least one of” and similar phrases are not intended to convey arequirement that each possible item must be present, although eachpossible item may be present.

The various embodiments described above are provided by way ofillustration only and should not be construed to limit the scope of thedisclosure. Various modifications and changes may be made to theprinciples described herein without following the example embodimentsand applications illustrated and described herein, and without departingfrom the spirit and scope of the disclosure.

1-20. (canceled)
 21. A system, comprising: at least one processor, andat least one non-transitory computer-readable storage medium havinginstructions stored which, when executed by the at least one processor,cause the at least one processor to perform operations comprising:configuring and initiating execution of a payment request applicationprogramming interface (API), the payment request API having executablecode distinct from an Internet browser, wherein the payment request APIperforms the steps of: generating a virtual payment informationassociated with browser-saved payment credentials, tokenizing thevirtual payment information, resulting in tokenized virtual paymentinformation, generating a query for the saved payment credentials forthe user from the merchant computer system, requesting the saved paymentcredentials from a third party database, and inserting the tokenizedvirtual payment information into corresponding fields of a paymentportion of the web page.